The high availability of critical services has become an important concern for many industries. The Service Availability Forum (SA Forum) (see, SA Forum, Overview SAI-Overview-B.05.03), which is a consortium of leading telecommunications and computing companies, has defined several standard interfaces to support the development of Highly Available (HA) systems. These standards aim at reducing the application development time and cost by shifting the availability management from applications to a dedicated middleware. Among those standards, the Application Interface Specification (AIS) supports the development of HA application by abstracting hardware and software resources. AIS defines the Availability Management Framework (AMF) (see, SA Forum, Application Interface Specification, Availability Management Framework SAI-AIS-AMF-B.04.01); a middleware service that manages the high availability of applications by coordinating their redundant components. In order to provide and protect the services, AMF requires a configuration that specifies the organization and the characteristics of the entities under its control.
AMF configurations are composed of logical entities representing services and software/hardware service provider resources. Each service imposes a specific workload on the service provider entities. AMF attains service availability by orchestrating the workload assignments among the redundant service provider entities.
Designing an AMF compliant configuration for a given application can be a tedious and error prone task due to the large number of attributes and numerous parameters to be taken into account. Researchers have developed an approach for the automatic generation of AMF configurations from a set of configuration requirements given by the configuration designer, and the description of the software defined by the software vendors (see, e.g., A. Kanso, M. Toeroe, A. Hamou-Lhadj, F. Khendek, “Generating AMF Configurations from Software Vendor Constraints and User Requirements,” Int. Conf. on Availability, Reliability and Security (ARES 2009). The approach succeeds in handling the complexity of the generation process, but it suffers from the low level of abstraction in the specification of configuration requirements (CR). The software is described in the Entity Types File (ETF) (see, SA Forum, Application Interface Specification, Software Management Framework SAI-AIS-SMF-A.01.02) in terms of entity prototypes, which characterize the deployment options and limitations of the different types of AMF logical entities implemented by the software. CR specify AMF services to be provided, the redundancy models to protect them, and the deployment infrastructure. However, configuration requirements are far from the formulation of the requirements that customers are accustomed to.
Some researchers have expressed application/user requirements as logical queries with logical operators, same for the requirements met by COTS components (see, e.g., L. Chung, W. Ma, K. Cooper, “Requirements Elicitation through Model-Driven Evaluation of Software Components,” pp. 187-196, Fifth International IEEE Conference on Commercial-off-the-Shelf (COTS)-Based Software Systems (ICCBSS'06), 2006). The application requirements are decomposed into a tree like structure and the resulting sub-queries are compared and matched with component requirements for ranking and selection. Search techniques such as simple key word based searching can be used. However, logical composition of key words generally cannot handle complete and complex user requirements.
In the field of Service-Oriented Architecture (SOA), Service Level Agreements (SLA) formally specify the conditions under which services need to be delivered. In this domain a research stream targets the analysis of the impact of SLA contracts (characterized by functional and non-functional descriptions) for web services on the infrastructure to be used for the provisioning of the services. Researchers have been investigating solutions for the mapping of SLA requirements into the layers of the SOA (see, e.g., T. Erl, Service-oriented architecture: concepts, technology, and design. 2005: Prentice Hall PTR Upper Saddle River, N.J., USA). However, SLAs are typically specified at the top-level of the infrastructure and no mechanism allows for the service providers to manage the underneath levels. Therefore, one of the most challenging research streams in the field of SOA is the investigation of SLA translation mechanisms.